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1. Abstract 


Many organizations use a firewall computer that acts as a security 
gateway between the public Internet and their private, internal 
‘intranet’. In this document, we discuss the issues surrounding the 
traversal of IP multicast traffic across a firewall, and describe 
possible ways in which a firewall can implement and control this 
traversal. We also explain why some firewall mechanisms - such as 
SOCKS - that were designed specifically for unicast traffic, are less 
appropriate for multicast. 


2. Introduction 


A firewall is a security gateway that controls access between a 
private adminstrative domain (an ’intranet’) and the public Internet. 
This document discusses how a firewall handles IP multicast [1] 
traffic. 


We assume that the external side of the firewall (on the Internet) 
has access to IP multicast - i.e., is on the public "Multicast 
Internet" (aka. "MBone"), or perhaps some other multicast network. 


We also assume that the *internal* network (i.e., intranet) supports 
IP multicast routing. This is practical, because intranets tend to 
be centrally administered. (Also, many corporate intranets already 
use multicast internally - for training, meetings, or corporate 
announcements.) In contrast, some previously proposed firewall 
mechanisms for multicast (e.g., [2]) have worked by sending *unicast* 
packets within the intranet. Such mechanisms are usually 
inappropriate, because they scale poorly and can cause excessive 
network traffic within the intranet. Instead, it is better to rely 
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upon the existing IP multicast routing/delivery mechanism, rather 
than trying to replace it with unicast. 


This document addresses scenarios where a multicast session is 
carried - via multicast - on both sides of the firewall. For 
instance, (i) a particular public MBone session may be relayed onto 
the intranet (e.g., for the benefit of employees), or (ii) a special 
internal communication (e.g., announcing a new product) may be 
relayed onto the public MBone. In contrast, we do not address the 
case of a roaming user - outside the firewall - who wishes to access 
a private internal multicast session, using a virtual private 
network. (Such "road warrior" scenarios are outside the scope of 
this document.) 


As noted by Freed and Carosso [3], a firewall can act in two 
different ways: 


1/ As a "protocol end point". In this case, no internal node 
(other than the firewall) is directly accessible from the 
external Internet, and no external node (other than the 
firewall) is directly accessible from within the intranet. 

Such firewalls are also known as "application-level gateways". 

2/ As a “packet filter". In this case, internal and external 
nodes are visible to each other at the IP level, but the 
firewall filters out (i.e., blocks passage of) certain packets, 
based on their header or contents. 


In the remainder of this document, we assume the first type of 
firewall, as it is the most restrictive, and generally provides the 
most security. For multicast, this means that: 


(i) A multicast packet that’s sent over the Internet will never 
be seen on the intranet (and vice versa), unless such packets 
are explicitly relayed by the firewall, and 

(ii) The IP source address of a relayed multicast packet will be 
that of the firewall, not that of the packet’s original 
sender. To work correctly, the applications and protocols 
being used must take this into account. (Fortunately, most 
modern multicast-—based protocols - for instance, RTP [4] - 
are designed with such relaying in mind.) 


3. Why Multicast is Different 
When considering the security implications of IP multicast, it is 


important to note the fundamental way in which multicast 
communication differs from unicast. 
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Unicast communication consists of a ’conversation’ between an 
explicit pair of participants. It therefore makes sense for the 
security of unicast communication to be based upon these participants 
(e.g., by authenticating each participant). Furthermore, ‘trust’ 
within unicast communication can be based upon trust in each 
participant, as well as upon trust in the data. 


Multicast communication, on the other hand, involves a arbitrary 
sized, potentially varying set of participants, whose membership 
might never be fully known. (This is a feature, not a bug!) Because 
of this, the security of multicast communication is based not upon 
its participants, but instead, upon its *data*. In particular, 
multicast communication is authenticated by authenticating packet 
data - e.g., using digital signatures - and privacy is obtained by 
encrypting this data. And ’trust’ within multicast communication is 
based solely upon trust in the data. 


4. Multicast-—Related Threats and Countermeasures 


The primary threat arising from relaying multicast across a firewall 
is therefore "bad data" - in particular: 


(i) damaging data flowing from the Internet onto the intranet, or 
(ii) sensitive data inadvertently flowing from the intranet onto 
the external Internet. 


To avert this threat, the intranet’s security administrator must 
establish, in advance, a security policy that decides: 


(i) Which multicast groups (and corresponding UDP ports) contain 
data that can safely be relayed from the Internet onto the 
intranet. For example, the security administrator might 
choose to permit the relaying of an MBone lecture, knowing 
that the data consists only of audio/video (& to safe ports). 

(ii) Which multicast groups (and corresponding UDP ports) will not 
contain sensitive internal information (that should therefore 
not be relayed from the intranet onto the Internet). This, 
of course, requires placing trust in the applications that 
internal users will use to participate in these groups. For 
example, if users use an audio/video '/viewer’ program to 
participate in an MBone session, then this program must be 
trusted not to be a "Trojan Horse". (This requirement for 
"trusted applications" is by no means specific to multicast, 
of course.) 


Once such a security policy has been established, it is then the job 
of the firewall to implement this policy. 
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5. What Firewalls Need to Do 


In short, a firewall must do three things in order to handle 
multicast: 


1/ Support the chosen multicast security policy (which establishes 
particular multicast groups as being candidates to be relayed), 

2/ Determine (dynamically) when each candidate group should be 
relayed, and 

3/ Relay each candidate group’s data across the firewall (and then 
re-multicast it at the far end). 


These three tasks are described in more detail in the next three 
sections. 


Note that because a firewall is often a convenient place to 
centralize the administration of the intranet, some firewalls might 
also perform additional administrative functions - for example, 
auditing, accounting, and resource monitoring. These additional 
functions, however, are outside the scope of this document, because 
they are not specifically *firewall*-related. They are equally 
applicable to an administrative domain that is not firewalled. 


6. Supporting a Multicast Security Policy 


As noted above, a multicast security policy consists of specifying 
the set of allowed multicast groups (& corresponding UDP ports) that 
are candidates to be relayed across the firewall. There are three 
basic ways in which a firewall can support such a policy: 


1/ Static configuration. The firewall could be configured, in 
advance, with the set of candidate groups/ports - for example, 
in a configuration file. 

2/ Explicit dynamic configuration. The set of candidate 
groups/ports could be set (and updated) dynamically, based upon 
an explicit request from one or more trusted clients 
(presumably internal). For example, the firewall could contain 
a ‘’remote control’ mechanism that allows these trusted clients 
- upon authentication - to update the set of candidate 
groups/ports. 

3/ Implicit dynamic configuration. The set of candidate 
groups/ports could be determined implicitly, based upon the 
contents of some pre-authorized multicast group/port, such as a 
"session directory". Suppose, for example, that the security 
policy decides that the default MBone SAP/SDP session directory 
[5] may be relayed, as well as any sessions that are announced 
in this directory. A ‘watcher’ process, associated with the 
firewall, would watch this directory, and use its contents to 
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dynamically update the set of candidates. 
Notes: 


(i) Certain ranges of multicast addresses are defined to be 
"administratively scoped" [6]. Even though the firewall 
does not act as a true multicast router, the multicast 
security policy should set up and respect administrative 
scope boundaries. 

(ii) As noted in [2], certain privileged UDP ports may be 
considered dangerous, even with multicast. The multicast 
security policy should check that such ports do not become 
candidates for relaying. 

(iii) Even if sessions announced in a session directory are 
considered automatic candidates for relaying (i.e., case 3/ 
above), the firewall’s /watcher’ process should still 
perform some checks on incoming announcements. In 
particular, it should ensure that each session’s ‘’group’ 
address really is a multicast address, and (as noted above) 
it should also check that the port number is within a safe 
range. Depending on the security policy, it may also wish 
to prevent any *locally* created session announcements from 
becoming candidates (or being relayed). 


7. Determining When to Relay Candidate Groups 


If a multicast group becomes a candidate to be relayed across the 
firewall, the actual relaying should *not* be done continually, but 
instead should be done only when there is actual interest in having 
this group relayed. The reason for this is two-fold. First, 
relaying a multicast group requires that one or both sides of the 
firewall join the group; this establishes multicast routing state 
within the network. This is inefficient if there is no current 
interest in having the group relayed (especially for 
Internet-—>intranet relaying). Second, the act of relaying an 
unwanted multicast group consumes unnecessary resources in the 
firewall itself. 


The best way for the firewall to determine when a candidate group 
should be relayed is for it to use actual multicast routing 
information, thereby acting much as if it were a real ’inter-domain’ 
multicast router. If the intranet consists of a single subnet only, 
then the firewall could listen to IGMP requests to learn when a 
candidate group has been joined by a node on this subnet. If, 
however, the intranet consists of more than one subnet, then the 
firewall can learn about candidate group memberships by listening to 
"Domain Wide Multicast Group Membership Reports" [7]. Unfortunately, 
this mechanism has only recently been defined, and is not yet used by 
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most routers. 


Another, albeit less desirable, way for the firewall to learn when 
candidate multicast groups have been joined is for the firewall to 
periodically 'probe’ each of these groups. Such a probe can be 
performed by sending an ICMP ECHO request packet to the group, and 
listening for a response (with some timeout interval). This probing 
scheme is practical provided that the set of candidate groups is 
reasonably small, but it should be used only on the intranet, not on 
the external Internet. One significant drawback of this approach is 
that some operating systems - most notably Windows 95 - do not 
respond to multicast ICMP ECHOs. However, this approach has been 
shown to work on a large, all-Unix network. 


Another possibility - less desirable still - is for each node to 
explicitly notify the firewall whenever it joins, or leaves, a 
multicast group. This requires changes to the node’s operating 
system or libraries, or cooperation from the application. Therefore 
this technique, like the previous one, is applicable only within the 
intranet, not the external Internet. Note that if multicast 
applications are always launched from a special "session directory" 
or "channel guide" application, then this application may be the only 
one that need be aware of having to contact the firewall. 


What makes the latter two approaches ("probing" and "explicit 
notification") undesirable is that they duplicate some of the 
existing functionality of multicast routing, and in a way that scales 
poorly for large networks. Therefore, if possible, firewalls should 
attempt to make use of existing multicast routing information: either 
IGMP (for a single-subnet intranet), or "Domain Wide Multicast Group 
Membership Reports". 


In some circumstances, however, the client cannot avoid contacting 
the firewall prior to joining a multicast session. In this case, it 
may make sense for this contact to also act as a ’notification’ 
operation. Consider, for example, an RTSP [8] proxy associated with 
the firewall. When the proxy receives a request - from an internal 
user - to open a remote RTSP session, the proxy might examine the 
response from the remote site, to check whether a multicast session 
is being launched, and if so, check whether the multicast group(s) 
are candidates to be relayed. 
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8. Relaying Candidate Groups 


The actual mechanism that’s used to relay multicast packets will 


depend upon the nature of the firewall. One common firewall 
configuration is to use two nodes: one part of the intranet; the 
other part of the external Internet. In this case, multicast packets 


would be relayed between these two nodes (and then re-multicast on 
the other side) using a tunneling protocol. 


A tunneling protocol for multicast should *not* run on top of TCP, 
because the reliability and ordering guarantees that TCP provides are 
unnecessary for multicast communication (where any reliability is 
provided at a higher level), yet would add latency. Instead, a UDP- 
based tunneling protocol is a better fit for relaying multicast 
packets. (If congestion avoidance is a concern, then the tunnel 
traffic could be rate-limited, perhaps on a per-group basis.) 


One possible tunneling protocol is the "UDP Multicast Tunneling 
Protocol" (UMTP) [9]. Although this protocol was originally designed 
as a mechanism for connecting individual client machines to the 
MBone, it is also a natural fit for for use across firewalls. UMTP 
uses only a single UDP port, in each direction, for its tunneleling, 
so an existing firewall can easily be configured to support multicast 
relaying, by adding a UMTP implementation at each end, and enabling 
the UDP port for tunneling. 


Notes: 


(i) When multicast packets are relayed from the intranet onto the 
external Internet, they should be given the same TTL that 
they had when they arrived on the firewall’s internal 
interface (except decremented by 1). Therefore, the internal 
end of the multicast relay mechanism needs to be able to read 
the TTL of incoming packets. (This may require special 
privileges.) In contrast, the TTL of packets being relayed 
in the other direction - from the external Internet onto the 
intranet - is usually less important; some default value 
(sufficient to reach the whole intranet) will usually 
suffice. Thus, the Internet end of the multicast relay 
mechanism - which might be less trusted than the intranet end 
- need not run with special privileges. 

(ii) One end of the multicast tunnel - usually the intranet end - 
will typically act as the controller (i.e., "master") of the 
tunnel, with the other end - usually the Internet end - 
acting as a "Slave". For security, the "master" end of the 
tunnel should be configured not to accept any commands from 
the "slave" (which will often be less trusted). 
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Ds 


10. 


Networks With More Than One Firewall 


So far we have assumed that there is only one firewall between the 
intranet and the external Internet. If, however, the intranet has 
more than one firewall, then it’s important that no single multicast 
group be relayed by more than one firewall. Otherwise (because 
firewalls are assumed to be application-level gateways - not proper 
multicast routers), packets sent to any such group would become 
replicated on the other side of the firewalls. The set of candidate 
groups must therefore be partitioned among the firewalls (so that 
exactly one firewall has responsibility for relaying each candidate 
group). Clearly, this will require coordination between the 
administrators of the respective firewalls. 


As a general rule, candidate groups should be assigned - if possible 
- to the firewall that is topologically closest to most of the group 
members (on both the intranet and the external Internet). For 
example, if a company’s intranet spans the Atlantic, with firewalls 
in New York and London, then groups with mostly North American 
members should be assigned to the New York firewall, and groups with 
mostly European members should be assigned to the London firewall. 
(Unfortunately, even if a group has many internal and external 
members on both sides of the Atlantic, only one firewall will be 
allowed to relay it. Some inefficiencies in the data delivery tree 
are unavoidable in this case.) 


Why SOCKS is Less Appropriate for Multicast 


SOCKS [10] is a mechanism for transparently performing unicast 
communication across a firewall. A special client library - 
simulating the regular ‘sockets’ library - sits between applications 
and the transport level. A conversation between a pair of nodes is 
implemented (transparently) as a pair of conversations: one between 
the first node and a firewall; the other between the firewall and the 
second node. 


In contrast, because multicast communication does not involve a 
conversation between a pair of nodes, the SOCKS model is less 
appropriate. Although multicast communication across a firewall is 
implemented as two separate multicast communications (one inside the 
firewall; the other outside), the *same* multicast address(es) and 
port(s) are used on both sides of the firewall. Thus, multicast 
applications running inside the firewall see the same environment as 
those running outside, so there is no need for them to use a special 
library. 
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Nonetheless, there has been a proposal [11] to extend SOCKS V5 to 


support multicast. This proposal includes two possible modes of 
communication: 
(i) "MU-mode", uses only *unicast* communication within the 


intranet (between the firewall and each internal group 
member), and 

(ii) "MM-mode", which uses unicast for client-to-firewall relay 
control, but uses *multicast* for other communication within 
the intranet. 


As noted in section 2 above, "MU-mode" would be a poor choice 
(unless, for some reason, the intranet does not support multicast 


routing at all). If multicast routing is available, there should 
rarely be a compelling reason to replace multicast with ‘’multiple- 
unicast’. Not only does this scale badly, but it also requires 


(otherwise unnecessary) changes to each application node, because the 
multicast service model is different from that of unicast. 


On the other hand, "MM-mode" (or some variant thereof) *might* be 
useful in environments where a firewall can learn about group 
membership only via "explicit notification". In this case each node 


might use SOCKS to notify the firewall whenever it joins and leaves a 
group. However, as we explained above, this should only be 
considered as a last resort - a far better solution is to leverage 
off the existing multicast routing mechanism. 


It has been suggested [11] that a benefit of using multicast SOCKS 
(or an “explicit notification" scheme in general) is that it allows 
the firewall to authenticate a client’s multicast "join" and "leave" 
operations. This, however, does not provide any security, because it 
does not prevent other clients within the intranet from joining the 
multicast session (and receiving packets), nor from sending packets 
to the multicast session. As we noted in section 3 above, 
authentication and privacy in multicast sessions is usually obtained 
by signing and encrypting the multicast data, not by attempting to 
impose low-level restrictions on group membership. We note also that 
even if group membership inside the intranet could be restricted, it 
would not be possible, in general, to impose any such membership 
restrictions on the external Internet. 


11. Security Considerations 


Once a security policy has been established, the techniques described 
in this document can be used to implement this policy. No security 
mechanism, however, can overcome a badly designed security policy. 
Specifically, network administrators must be confident that the 
multicast groups/ports that they designate as being ’safe’ really are 
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free from harmful data. In particular, administrators must be 
familiar with the applications that will receive and process 
multicast data, and (as with unicast applications) be confident that 
they cannot cause harm (e.g., by executing unsafe code received over 
the network). 


Because it is possible for an adversary to initiate a "denial of 
service" attack by flooding an otherwise-legitimate multicast group 
with garbage, administrators may also wish to guard against this by 
placing bandwidth limits on cross-firewall relaying. 


12. Summary 


Bringing IP multicast across a firewall requires that the intranet 
first establish a multicast security policy that defines which 
multicast groups (& corresponding UDP ports) are candidates to be 
relayed across the firewall. The firewall implements this policy by 
dynamically determining when each candidate group/port needs to be 
relayed, and then by doing the actual relaying. This document has 
outlined how a firewall can perform these tasks. 
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